Thank you very much. I'll be sure to experiment with it.

Gladly – and thanks for merging 🤗 Activated now at our end, so any changes you apply would be synchronized whenever a new release is being pulled in. Should your experiments raise questions, be welcome to ask 😉

Whenever you add a new "type" of metadata that has not been there before (e.g. the first changelog, a featureGraphic if it wasn't yet present), please let us know so we can check and enable it.

@IzzySoft I reckon 63a22d2 and ed83037 qualify?

Yupp: changelogs added it is, right? Done.

Btw: your app is on the monthly track currently, as there haven't been updates in a while. If that's OK with you (as you don't plan updates more than twice a year), we can leave it at that – otherwise, we can put it on the daily checks again. For the current release, I'll just trigger an update manually now.

Oopsie:

! repo/com.androidvip.sysctlgui_23.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

mind to add some lines to your build.gradle for the next release?

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs (for IzzyOnDroid/F-Droid)
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles (for Google Play)
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. in our documentation on Signing Block Checks at our website, and in our blog article Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Err… and mind to keep the naming pattern of your attached APK files consistent, so our updater finds them? sysctgui lacks a letter 😉 For the next release – please do not change the current one anymore.

OK, update was successful – but RB failed, with a tiny difference in classes.dex:

 |: sget-object v1, LN3/d;.a:Landroidx/compose/material3/G4;
-|: const/16 v3, #int 24576 // #6000
+|: const/16 v3, #int 27648 // #6c00
 |: move-object/from16 v13, v123

Any idea what that might be caused by? Subtracting the two are pretty close to the time difference between your build and ours. I hope that's only coincidence, and you didn't include something dependent on build time?

1. That's ok, twice or maybe thrice a year is what I can do, for now.
2. Sorry for the typo. It's already set, right? Fixing the name will be only relevant for the next release, right?
3. Again, no idea what is that difference. That APK was built from my local machine, from the develop branch right after the release pull request was merged. If we're checking time differences, it happened pretty much between the merge, the build time and the release time.

Thanks for the heads up.

1. OK, then we leave it at "monthly" for now. Just know you can always ping us to change it when needed (or open your own PR for it at https://codeberg.org/IzzyOnDroid/repodata)
2. yupp, is set (RegEx was amended to allow for a missing l). We just want to avoid having it ending up in .*, as that defeats its pupose 😉
3. local machine runs what OS/version? And what JDK are you using? Would using Github actions for building the release APK (building, not signing – the latter can of course happen locally, so you don't have to "hand over" your secrets) be an option?

The machine is currently running Windows (yes) 11 25H2 26200.7623. Gradle runs JerBrains Runtime 21.0.8 although JAVA_HOME is Microsoft's OpenJDK build 17.0.16.

Yes, building on GitHub actions is an option.

JerBrains Runtime 21.0.8

JetBrains you mean? OK, I give up then. One of those shenanigans again, which you never can pinpoint. I've tried with OpenJDK 21 as well, results are identical. JetBrains is known to cause such things every now and then.

So when switching to GHA, please pick something else (we've good experience with temurin there for example).

We'll have to pass the "RB failed" then today. I'll anyhow commit the recipe with JDK 21, as I assume your setup will be

• temurin JDK 21
• ubuntu noble (the default GHA currently uses; they name it ubuntu:latest, but for RB it's best to not rely on "moving targets"

Our last recipe now is set with OpenJDK 21 on Debian trixie. We can of course adjust when needed.

Looking forward to the next release then, and fingers crossed 🤞